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Summary 

Future lunar surface missions supporting the NASA Vision for Space Exploration will rely on 
wireless networks to transmit voice and data. The ad hoc network architecture is of particular interest 
since it does not require a complex infrastructure. In this report, we looked at data performance over an 
ad hoc network with varying distances between Apple AirPort wireless cards. We developed a testing 
program to transmit data packets at precise times and then monitored the receive time to characterize 
connection delay, packet loss, and data rate. Best results were received for wireless links of less than 
75 ft, and marginally acceptable (25-percent) packet loss was received at 150 ft. It is likely that better 
results will be obtained on the lunar surface because of reduced radiofrequency interference; however, 
higher power transmitters or receivers will be needed for significant performance gains. 

Introduction 

The availability of robust, lightweight voice and data communication is critical to the success of lunar 
surface missions supporting the NASA Vision for Space Exploration. The development of wireless 
surface networks integrating computing and data storage, as well as sensor network interfaces and 
controls, will be essential for future exploration missions (Refs. 1 and 2). Wireless architectures offer 
human and robotic explorers all the benefits of a wired network without the restrictions of wires. Ad hoc 
mesh networks, in particular, take a straightforward approach to data communication among rovers, 
habitats, and astronauts because they do not rely on complex infrastructure. These networks also provide 
greater scalability since configurations can be changed easily to support a dynamic number of interfaces. 

The fault tolerance, reliability, and expandability of ad hoc wireless networks must be evaluated if 
they are to be considered for applications in the core exploration architecture. In this report, we 
investigate the data flow performance of an ad hoc networking configuration based on the IEEE 802.1 lg 
wireless standard. We examine the characteristics of data packet delay and packet loss. We also look at 
the observed data rate relative to the transmitted data rate. The measurement data will help to determine 
an approximate range at which a standard laptop 802.1 lg transceiver could be used for lunar surface area 
communications. 


802.11 Wireless Communication 

The IEEE 802.1 lg protocol was developed to specify an over-the-air interface between a wireless 
user and an access point in infrastructure mode, or between two wireless users in an ad hoc setup. Data 
communication is accomplished by encoding packets and then transmitting them serially over the 
physical medium to a remote station. The ad hoc architecture configuration shown in Figure 1 allows two 
nodes equipped with 802.1 lg wireless adapter cards to set up an independent network when they are 
within range of one another. A node could be a computer, as in our analysis, or another electronic device, 
like a sensor. 
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Figure 1 . — Wireless ad hoc network architecture. 

Table I shows the specifications for the various IEEE 802.1 1 wireless protocols. The 802.1 lg 
approach specifies a burst rate of 54 megabits per second (Mbps) using orthogonal frequency division 
multiplexing in the 2.4-GHz Industrial, Scientific, and Medical (ISM) unlicensed band. This frequency 
range is shared with other wireless systems, and thus, it must operate in a noninterfering fashion (i.e., 
through collision-avoidance and carrier-sensing mechanisms). The IEEE 802.1 lg and 802.1 la protocols 
theoretically can transfer data five times faster than 802.1 lb. However, because of protocol and packet 
processing overhead, actual network data rates typically are lower than the nominal maximum rate. In 
addition, wireless networks tend to experience interference that results in erosion of throughput. 

TABLE I.— SPECIFICATIONS FOR IEEE 802.11 WIRELESS PROTOCOLS 


[Ref. 3.] 



Specification 

WiFi a 

IEEE 802.11a 

WiFi 

IEEE 802.11b 

WiFi 

IEEE 802.1 lg 

Standard approval 

July 1999 

July 1999 

June 2003 

Maximum data rate, Mbps 

54 

11 

54 

Modulation 

OFDM b 

CCK C 

OFDM, CCK 

Supported data rates, Mbps 

6, 9, 12, 18, 

1,2, 5.5, 11 

CCK: 1,2, 5.5, 11 


24, 36, 48, 54 


OFDM: 6, 9, 12, 18, 24, 36, 48, 54 

Frequencies, GHz 

5.15 to 5.35 

2.4 to 2.497 

2.4 to 2.497 


5.425 to 5.675 




5.725 to 5.875 



Approximate theoretical 

40 (54) 

170(11) 

65 (54) 

range, ft (Mbps) 

125(11) 

260 (2) 

180(11) 


150 (2) 


260 (2) 


Certification of the Wi-Fi Alliance that is based on the IEEE 802.1 1 standards and that ensures 
interoperability between wireless devices. 
b Orthogonal frequency division multiplexing. 

Complementary Code Keying. 


Testing Configuration 

The in-house packet transceiver program in Figure 2 was written for the wireless evaluations. 

Existing network performance testing toolkits can perform similar tasks, but often it is not possible to 
characterize any added instruction overhead. Instead, simplistic code was developed to minimize 
processing delays. 

The testing program was split into two major parts: a controller and node. The controller is the central 
interface for network testing, responsible for instructing specific nodes to transmit information to other 
nodes. The node program, therefore, handles both transmit and receive functionality. By default, a node 
listens constantly for commands and data. A separate instance of the node program, called a child process, 
is created when a node receives a command to transmit packets. This allows simultaneous data flows to 
originate from a single node. Meanwhile, the node continues to listen for test data on its local receive 
port. Statistics are updated as each data packet arrives on the proper port. 

Several implementation decisions were made to reduce the complexity of the testing architecture. A 
single laptop acted as both the controller and the transmitter, to allow for a smaller mobile system size. 
Minimal network overhead was added because of communication between the two programs on the same 
system; the local loopback protocol was used to deliver the initial transmit command. The packet payload 
size was set at 982 bytes in order to pad the entire packet to 1024 bytes when considering the standard 
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control { 

1 . Create sockets pointing at each of the transmit nodes. 

2. Continuously poll the command line for user commands. 

a) “quit” : Tell each node to display statistics and terminate. 

b) “help” : Print usage information for available commands. 

c) “transmit” : Send a ‘transmit’ command to the desired node. 

> 

node { 

1 . Listen for control messages (port 5000) and data packets (port 5001). 

2. Reset packet size, packet number, and error counters; open a log file. 

3. Continuously poll for data on all ports, non-blocking, until ‘break’. 

If (test data is received) 

a) Record receive time for the first and most recent packet. 

b) Increment the byte counter. 

c) Parse the packet number; check to see if the packet is sequential. 

Else if (control data is received) 

a) “quit”: Break out of continuous polling mode. 

b) “transmit”: Call p_transmit() to send packets. 

4. Print the number of bytes received and calculate a data rate. 

} 

p_transmit { 

1 . Create a UDP/IP socket pointing to the remote node. 

2. Create an independent child process and terminate the p_transmit() parent process. 

3. Construct a UDP/IP/Ethernet packet, and fill a 982-byte payload with OxFF. 

4. Transmit the desired number of packets. 

a) Fill bytes 0 and 1 of the packet with a sequential packet number. 

b) Transmit the single packet over the socket to the destination host. 

c) Delay for a number of milliseconds. 

> 

Figure 2. — Custom packet transceiver program for performing packet data analysis. UDP, User Datagram 
Protocol: IP, Internet Protocol. 

8-byte User Datagram Protocol (UDP) header, 20-byte Internet Protocol (IP) header, and 14-byte Ethernet 
header. In addition, a 16-bit packet number was appended to the beginning of the payload to help 
determine whether arriving packets were sequential. 

Both UDP and IP have characteristics that make them adept at performance testing (Ref. 4). UDP is a 
connectionless, stateless protocol, which reduces packet timing overhead by eliminating items such as 
congestion control, throttling, and handshaking procedures. In addition, UDP does not provide error 
correction: lost packets are not retransmitted, and corrupt packets are either delivered as-is or are dropped, 
depending on the implementation. IP provides minimal interference in the transmission process. A 
checksum is computed over the IP header, but otherwise no error correction or retransmission takes place 
at the network layer. 

The testing environment for the wired and wireless systems is shown in Figure 3, parts (a) and (b), 
respectively. All tests were conducted using the same transmit and receive programs, laptops, and UDP/IP 
configuration parameters. The UDP port and IP address were chosen arbitrarily, and the Media Access 
Control (MAC) address was defined by the network card. Since the network hub used for the wired 
testing is limited to around 10-Mbps throughput, the theoretical testing data rates were kept far below 
this threshold. 
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Figure 3. — Testing environment. UDP, User Datagram Protocol; IP, Internet 
Protocol; NIC, network interface card; l/F, interface, (a) Wired systems. 

(b) Wireless systems. 


Testing and Results 

For each test, 1000 packets were transmitted to the receiver with a timed delay of 100 ms between 
each packet. Wireless tests were conducted outdoors using a line-of-sight link; however, the test area 
contained several trees that could contribute to radiofrequency scattering effects. Figure 4(a) shows 
measurement results for observed packet delay in the wired testing environment. Results for the wireless 
testing environment are exhibited in Figures 4(b) to 4(e), with distances between the transmitter and 
receiver of 1, 75, 150, and 200 ft, respectively. 

Table II shows packet transmission characteristics for the wired and wireless tests. The number of 
packets transmitted but never received increased up to 27.1 percent as the distance between the trans- 
mitter and receiver reached 150 ft. When the distance was extended to 200 ft, only 0.5 percent of the 
packets were received from the transmitter. Data rate refers to the average calculated throughput from the 
time that the first packet was received until the time that the last packet was received. The highest data 
rate was seen for a wireless range of 1 ft; however, no test showed a remarkable drop in throughput. A 
high data rate would have been possible despite large packet loss if all the received packets arrived in a 
compact group. 
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Figure 4. — Measurement results for observed packet delay, (a) Wired connection, (b) Wireless connection (1 ft), 
(c) Wireless connection (75 ft), (d) Wireless connection (150 ft), (e) Wireless connection (200 ft). 


TABLE II.— PACKET TRANSMISSION CHARACTERISTICS 


FOR WIRED AND WIRELESS TESTS 


Network type 
(distance 
transmitted) 

Average 

delay, 

ms 

Standard 

deviation, 

ms 

Packet 

loss, 

percent 

Data rate, 
byte s/s 

Ideal transmitted 

100 

0 

0.0 

10240.0 

Wired 

100 

11 

.0 

9939.7 

Wireless (1 ft) 

100 

0.6 

.0 

10238.3 

Wireless (75 ft) 

100 

15 

.4 

10198.4 

Wireless (150 ft) 

105 

76 

27.1 

9811.5 

Wireless (200 ft) 

(a) 

(a) 

99.5 

8722.3 


a Could not be computed because of excessive packet loss. 
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Delay, ms 

Figure 5. — Cumulative packets arrived by time for wired and wireless tests. 

Total 1000 packets sent; 1000-ms desired delay. 

Figure 5 shows the amount of cumulative packets arrived versus time for wired and wireless network 
tests. The best results are indicated by a sharp increase around the 100-ms mark. In general, the delay 
time required to reach 100-percent packet arrival became larger as the distance between the transmitter 
and receiver increased. 


Discussion 

The data in Table II show a clear trend toward less reliable wireless communication as the distance 
between the transmitter and receiver increases. It appears that the 802.1 lg card evaluated in this test can 
cover effectively a range of about 75 ft with minimal packet loss. A majority of the packets still arrived at 
150 ft; however, approximately 25 percent of the packets were lost, which may not be acceptable for 
some real-time applications like voice or streaming video. Communication was lost almost completely 
when the transmitter and receiver were separated by 200 ft, with only 5 out of 1000 packets being 
received at this distance between the transmitter and receiver. 

We expected that the wired network test would provide a result close to the ideal performance level; 
however, the results demonstrate that this was not the case. Figure 5 shows that approximately half of the 
packets arrived very close to the transmitted 100-ms delay and that the remainder arrived by around 
112 ms. We do not think that the network hub reduced system performance, because a hub is a passive 
device and all packets would be delayed equally. Therefore, since IP and UDP do not provide conges- 
tion control, it is likely that the Ethernet card or the driver involved in the test provided some type of 
packet buffering. 

Figure 5 shows that a number of packets from the wireless tests arrived well before the 100-ms mark. 
We observed that, as distance increased, packets tended to be more clustered. A significantly delayed 
packet was often followed quickly by the subsequent packet. This could be due to the multipath effects of 
the testing environment or to error-correcting retransmission algorithms within the wireless network card. 
It is possible that the 802.1 lg firmware contains error detection and correction functionality that was not 
controllable within the test environment. 


Conclusions 

The 802.1 lg wireless performance test showed that a standard wireless network card provides best 
performance up to approximately 75 ft. Tests beyond that distance resulted in increased packet loss and 
slower data rates. 

IEEE 802.1 lg communication is subject to interference by a number of terrestrial technologies, 
including cordless phones and Bluetooth devices operating at 2.4 GHz. However, it is unlikely that a 
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communication network operating on the lunar surface will see the same adverse effects to the extent 
reflected in our data. 

The advantage of using the ad hoc network architecture presented in this report is that it requires no 
administration or preconfiguration. However, the drawback is that communication is limited to a very 
short range. Because of this restriction, on the lunar surface the ad hoc network likely is more suited for 
data communication among astronauts within close proximity. 

Future Work 

We identified additional areas of research on this topic. Because of the uncertainties in error 
correction associated with the network cards used in the project, it would be useful to study the 
performance of a pure 802.1 lg implementation on a field-programmable gate array platform. It would 
also be helpful to observe the effects of adding amplifiers or high-gain antennas to the study. Further 
research could be performed to draw comparisons to similar terrestrial communication standards, such as 
802. 16e (mobile WiMAX) or cellular protocols. 
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